feat(web): dock the state-grouped fleet beside the conductor's chat - #325

conductor-design §3 specifies that the fleet READ verbs — fleet_list,
fleet_find, fleet_summary, fleet_recall, fleet_tasks, machine_map — "run
silently". They did not. `isSafeTool` knew the memory and blackboard
mounts but not the fleet, so in guarded mode every one of them raised an
approval prompt.

Found by driving a real conductor rather than reading the code: asking it
to resolve a session reference produced an approval request for
`fleet_find`, which is a read. An assistant that asks permission to look
something up is not an assistant, and this is the first friction anyone
meets in the new conductor pane (#325).

The daemon already put these verbs in the provider's `allowedTools`, so
the SDK warned it would auto-approve them — but codeoid's own gate is
consulted independently and did not recognise them, which is why the two
disagreed.

Follows the established shape exactly: match the namespace prefix, then
require the suffix to be a known read verb. Never a bare prefix match — an
over-broad match here is a prompt bypass, which is why a look-alike
segment (`mcp__evil_codeoid_fleet__…`) is asserted to gain nothing.

The read list is `FLEET_READ_TOOLS` from the shared protocol package, so
the send half cannot leak in by someone editing one of two copies. Send
verbs remain hard-gated BEFORE this function is consulted
(`isFleetSendTool` in Session#shouldAutoApprove, checked ahead of any mode
logic); this is defence in depth, not the fence.

Verified live, both directions. With the fix, fleet_list / fleet_find /
machine_map go straight to `executing` with zero prompts; fleet_spawn
still lands in `waiting_confirmation` and waits for the owner. The R3
invariant is intact.

Also lists the bare (non-`mcp__`) namespacing so a mounted fleet (#245)
does not silently regress to prompting on every read.

10 tool-safety tests; 2452 daemon tests; typecheck and lint clean.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix(conductor): let the fleet read surface run without prompting

conductor-design §3 specifies that the fleet READ verbs — fleet_list,
fleet_find, fleet_summary, fleet_recall, fleet_tasks, machine_map — "run
silently". They did not. `isSafeTool` knew the memory and blackboard
mounts but not the fleet, so in guarded mode every one of them raised an
approval prompt.

Found by driving a real conductor rather than reading the code: asking it
to resolve a session reference produced an approval request for
`fleet_find`, which is a read. An assistant that asks permission to look
something up is not an assistant, and this is the first friction anyone
meets in the new conductor pane (#325).

The daemon already put these verbs in the provider's `allowedTools`, so
the SDK warned it would auto-approve them — but codeoid's own gate is
consulted independently and did not recognise them, which is why the two
disagreed.

Follows the established shape exactly: match the namespace prefix, then
require the suffix to be a known read verb. Never a bare prefix match — an
over-broad match here is a prompt bypass, which is why a look-alike
segment (`mcp__evil_codeoid_fleet__…`) is asserted to gain nothing.

The read list is `FLEET_READ_TOOLS` from the shared protocol package, so
the send half cannot leak in by someone editing one of two copies. Send
verbs remain hard-gated BEFORE this function is consulted
(`isFleetSendTool` in Session#shouldAutoApprove, checked ahead of any mode
logic); this is defence in depth, not the fence.

Verified live, both directions. With the fix, fleet_list / fleet_find /
machine_map go straight to `executing` with zero prompts; fleet_spawn
still lands in `waiting_confirmation` and waits for the owner. The R3
invariant is intact.

Also lists the bare (non-`mcp__`) namespacing so a mounted fleet (#245)
does not silently regress to prompting on every read.

10 tool-safety tests; 2452 daemon tests; typecheck and lint clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat(web): Conductor ⇄ Sessions toggle

Completes P5.1 (docs/conductor-frontends-design.md §3.A). Two co-equal
top-level homes with one control in the status bar.

§3 is the constraint the whole feature rests on: the conductor is a LENS
over the same sessions, never a wall, and there must be no state a user
can get stuck in. So this is a navigation preference, not a mode —
switching home changes which session you are looking at and nothing else,
and every session stays reachable from the list in both homes.

**Sessions stays the default, even once a conductor exists.** Silently
relocating someone's home the first time they spawn a conductor is
exactly the "trapped in an orchestrated mode" feeling §3 exists to
prevent, and a user who wants the conductor is one click away — then
remembered. This settles the "default home" question left open in §13.

The resolution rules live in `lib/home.ts` as pure functions, since which
session a home lands on is the decision worth testing:

- Conductor home focuses the conductor, or does NOTHING when there is
  none — a normal state, not an error. `null` means "leave focus alone",
  deliberately distinct from "focus nothing", so re-selecting a home you
  are already on does not reset scroll for nothing.
- Sessions home acts only when you are actually sitting on the conductor.
  Otherwise you are already somewhere in Sessions and moving you would be
  the surprise this design avoids.
- It returns you to the session you came from, falling back to the first
  ordinary session when that one was destroyed.

Workers are never a landing target, on either path. They are disposable
and die with their task, so landing on one is landing somewhere about to
disappear — and a worker can legitimately be the last thing you looked
at, having drilled into it from the fleet rail. A test caught that: the
remembered-session path originally excluded only conductors.

Acting on the choice is an effect rather than click handling, so the two
stay consistent when the population changes underneath — the conductor
being created while Conductor home is already selected, for instance.

The preference persists via the existing layout store, validated on read
rather than cast: a stored value from a future build must fall back, not
select a home that does not exist. The remembered session is deliberately
NOT persisted — it is a within-visit convenience, and an id from days ago
is likelier to name a destroyed session than to be useful.

11 home tests; 210 web tests; typecheck, lint and build clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* refactor(web): name the ordinary-session predicate, keep its fail-safe

Review follow-up on #329 (Oracle, both comments).

The feedback asked for an explicit role taxonomy instead of
`s.role === undefined`, suggesting `role !== "conductor" && role !==
"worker"`. Taking the first half and declining the second.

**Taken: name it.** The check was an inline lambda in `home.ts` and a
duplicated inline test in `HomeToggle.tsx`. Both now call an exported
`isOrdinarySession`, so the taxonomy has a name and one definition.

**Declined: the negative form**, because it inverts the safety property.
`SessionInfo.role` is documented as "Absent = normal session", and the
protocol deliberately anticipates roles this client has not heard of —
`session.create` types its role as an open string precisely "so a future
role from a newer client still type-checks on the wire". The two forms
therefore differ exactly when a new role appears:

  role === undefined           → an unknown role is NOT ordinary (excluded)
  role !== "conductor" && ...  → an unknown role IS ordinary     (included)

The negative form reads as more explicit and is the more dangerous of the
two: it silently opts every future session kind into being a focus
target. Workers are excluded here because they vanish with their task;
inheriting that risk for kinds we know nothing about is the wrong
default. An unknown role now stays excluded until somebody adds it here
deliberately.

Pinned by two tests — one on the predicate, one through `homeTarget` —
that a session with an unrecognised role is never a landing target.

14 home tests; 213 web tests; typecheck, lint and build clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>